This PR aims to address the second of Sarah's concerns from the source branch. Namely, that the state files and manifest file are still be written even if they are empty / didn't error.

I did find the existing implementation of the manifest file to be confusing. States were being loaded and written at seemingly random times, and there was overlap between when things were being written into backends and into local files. There are two driving changes in this PR that I think simplify things a little bit:

1. The presence of an entry in the manifest file is now enough for the manifest file to know directly whether a state is empty or not. Empty states will simply not be written to the manifest, so the we don't need to load the state outside the graph to try and decide whether we can execute a test or not. If the manifest file has states for a given run in it, then that run needs to be cleaned up before it can execute. We don't need to parse the state files to know this.
2. The manifest file itself is no longer provided directly into the test graph. Instead, the states are loaded and saved externally, with the graph just needing to be keep them updated in memory. The graph isn't then sometimes writing data into backends, sometimes not, sometimes writing things to files, etc. This all happens now in a single place after the file has finished executing.

This change did end up being larger than I expected, as I needed to move things around in quite a large number of places in order to get the kind of access needed to make the state loading work as intended. For that, I'm sorry. But, hopefully most of the smaller changes are just simple refactorings that you can understand.

There is also one behaviour change. When a run block with a backend fails to get destroyed, an entry is written into the manifest for that state file but it is no longer directly persisted to disk. Instead, the state as it exists with the failed destroy is written directly into the actual state backend. So, we have an entry in the manifest locally telling us the execution failed, but we don't keep duplicate copies of the state file around. Instead, during cleanup, the errored state is just loaded from the backend like normal instead of trying to sideload it locally. It seemed redundant and dangerous to hold competing copies of a state file in two locations.